home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19941031-19941221 / 000233_news@columbia.edu_Tue Nov 22 14:31:55 1994.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA11635
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Tue, 22 Nov 1994 09:32:01 -0500
  3. Received: by apakabar.cc.columbia.edu id AA27123
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Tue, 22 Nov 1994 09:31:59 -0500
  5. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  6. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  7. Newsgroups: comp.protocols.kermit.misc
  8. Subject: Re: Help: file transfer problem
  9. Date: 22 Nov 1994 14:31:55 GMT
  10. Organization: Columbia University
  11. Lines: 30
  12. Message-Id: <3asvcr$qfg@apakabar.cc.columbia.edu>
  13. References: <CzMLA2.K01@liverpool.ac.uk> <3aqlhu$7q6@apakabar.cc.columbia.edu> <CHANG.94Nov21182356@theta.math.wsu.edu>
  14. Nntp-Posting-Host: watsun.cc.columbia.edu
  15. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  16.  
  17. In article <CHANG.94Nov21182356@theta.math.wsu.edu>,
  18. Ching Mo Chang <chang@theta.math.wsu.edu> wrote:
  19. >I also have the file upload problem with MS-Kermit (Also C-Kermit in OS/2),
  20. >I can download file with packets length at 5012, but when I use the same
  21. >setting to upload file I got lots of timeout and eventually end up too many
  22. >retries error and fail to upload file. If I really need to upload file, I
  23. >need to increase the retry limit and set the packets length to 92, let the
  24. >file crawl from my PC to the host or I will just paste the file into an editor
  25. >in my host side (only work in ASCII file).
  26. >
  27. This is not Kermit's fault.  You should be thankful that Kermit lets you
  28. adjust these parameters to make the file transfer work at all.  Why is this
  29. happening?  It's hard to say without more information, but the most likely
  30. culprit is a lack of buffer capacity in the "upstream" direction, coupled
  31. with a lack of effective flow control -- a fatal combination, and a common
  32. one.
  33.  
  34. Many communications processors (terminal servers, front ends, host console
  35. drivers) are designed on the assumption that traffic *to* the host consists
  36. of nothing but keystrokes -- which hardly anybody can produce at more than
  37. about ten per second (= 100 bps) -- whereas traffic in the downstream
  38. direction is voluminous -- file listings, etc.  So they have big output
  39. buffers and tiny input buffers.
  40.  
  41. To compound the problem, some communications processors take this assumption
  42. one step further and do not even provide flow control in the upstream
  43. direction, because they figure they will never need it.  A well-known example
  44. is the Cisco ASM series of terminal servers.
  45.  
  46. - Frank